1. Propos et objectifs

Cette documentation définit les conditions, exigences et formats relatifs à la réalisation des tests dans le cadre du développement de la solution basée sur ABP.io :

• Backend : .NET (ABP Framework, Domain Driven Design, EF Core)
• Frontend : Angular
• Outils de qualité : SonarCube (analyse statique), Azure DevOps CI/CD

Objectifs

• Acter les pratiques communes des équipes Frontend et Backend
• Assurer une qualité logicielle mesurable
• Garantir la compatibilité avec les outils d’intégration continue et d’analyse

2. Identification des fonctionnalités critiques

2.1. Définition

Une fonctionnalité est dite critique lorsqu’une défaillance de celle-ci :

• compromet la disponibilité, la sécurité ou la cohérence du système ;
• empêche l’utilisateur final de réaliser une action clé ;
• a un impact direct sur les transactions, la conformité ou les performances globales.

2.2. Méthodologie d’identification

Les fonctionnalités critiques doivent être identifiées à chaque Sprint Planning/Raffinage par les développeurs selon les critères suivants :

Critère	Exemple concret
Transaction financière	Validation d’une commande, gestion de facturation
Sécurité / Authentification	Login, gestion des rôles, tokens JWT
Données sensibles	Accès / mise à jour des données personnelles
Processus métier clé	Workflow de validation, génération de rapports légaux
Intégration externe	Appels API tierces, synchronisation avec systèmes partenaires

2.3. Marquage dans le code

Les tests associés aux fonctionnalités critiques doivent être explicitement identifiés par un tag ou un attribut :

• Backend : [Trait("Critical", "true")]
• Frontend : describe('[Critical]', () => {...})

Cela permet :

• la filtrage automatique dans Azure Pipelines (tests prioritaires) TODO: A tester,
• et l’analyse de couverture spécifique via SonarCube.

3. Couverture de tests

3.1. Objectifs de couverture

Type de test	Niveau attendu	Objectif
Tests unitaires	≥ 80% du code métier	Garantir la fiabilité des composants
Tests d’intégration	100% des services critiques	Vérifier la cohérence inter-couches
Tests end-to-end (E2E)	Parcours utilisateur principaux	Garantir la non-régression fonctionnelle TODO: A détailler
Tests de performance	Scénarios critiques	Contrôler les temps de réponse
Tests de sécurité	Auth, autorisation, injections	Prévenir les vulnérabilités

> Les rapports de couverture (JaCoCo / Coverlet / Istanbul) doivent être publiés automatiquement dans Azure DevOps. TODO: A tester

4. Format des tests Frontend (Angular)

4.1. Objectifs

• Garantir la compatibilité avec SonarCube (analyse statique JS/TS)

• Faciliter l’exécution dans Azure CI/CD

• Normaliser les pratiques de test Angular

4.2. Frameworks et outils TODO: A tester

Type	Outil
Tests unitaires	Jasmine + Karma
Tests d’intégration	Jest (optionnel)
Tests E2E	Cypress
Analyse statique	ESLint + SonarJS

4.3. Conventions de test

• Chaque fichier TypeScript doit avoir un fichier .spec.ts correspondant.
• Les tests doivent suivre la structure suivante :

describe('ComponentNameComponent', () => {
  let component: ComponentNameComponent;
  let fixture: ComponentFixture<ComponentNameComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [ComponentNameComponent],
      imports: [HttpClientTestingModule]
    }).compileComponents();
  });

  it('devrait créer le composant', () => {
    expect(component).toBeTruthy();
  });
});

4.4. Analyse CodeSonar

• Les règles ESLint SonarJS doivent être activées : "extends": ["eslint:recommended", "plugin:@angular-eslint/recommended", "plugin:sonarjs/recommended"]
• Les alertes doivent être corrigées ou justifiées avant la fusion en branche principale.

5. Format des tests Backend (.NET – ABP.io)

5.1. Objectifs

• Assurer la compatibilité avec CodeSonar (.NET analysis)

• Automatiser les tests dans Azure CI/CD

• Normaliser les pratiques selon ABP.io Abp Tests

5.2. Frameworks et outils

Type	Outil
Tests unitaires	xUnit
Tests d’intégration	ABP TestBase
Mocking	Moq
Couverture	Coverlet
Analyse statique	CodeSonar CLI / Roslyn analyzers

5.3. Conventions

ABP.io test d'intégration

• Un test unitaire doit être isolé du contexte (mock de repository, services, etc.)

• Les tests d’intégration doivent utiliser les modules ABP TestBase TODO: A valider :

public class MyAppTestBase : AbpIntegratedTest<MyAppModule>
{
    protected override void BeforeAddApplication(IServiceCollection services)
    {
        // Configuration spécifique aux tests
    }
}

• Exemple :

public class UserServiceTests : IClassFixture<MyAppTestBase>
{
    [Fact]
    [Trait("Critical", "true")]
    public async Task Should_Create_User_Successfully()
    {
        // Arrange
        var service = GetRequiredService<IUserAppService>();
        // Act
        var result = await service.CreateAsync(new CreateUserDto { Name = "Test" });
        // Assert
        Assert.NotNull(result);
    }
}

6. Bonnes pratiques communes Front / Back

Pratique	Description
Tests automatiques dans les PRs	Tout code fusionné doit avoir ses tests passants dans Azure
Convention de nommage	Les fichiers de test suivent le pattern <nom>.spec.ts (Front) / <nom>Tests.cs (Back)
Revue de couverture	Seuil minimal défini par pipeline : 80% (bloquant si inférieur)
Linting + Sonar	Le pipeline échoue si des violations critiques sont détectées
Documentation des tests	Chaque test doit indiquer le cas métier testé dans un commentaire clair
Rapports	Les rapports (JUnit, Cobertura, SonarQube) doivent être exportés dans Azure DevOps

7. Conclusion

Cette politique de tests unifiée :

• garantit la qualité logicielle de bout en bout,

• assure la traçabilité et la mesurabilité des efforts de test,

• et permet une intégration fluide avec CodeSonar et Azure DevOps CI/CD.

Les équipes Frontend et Backend s’engagent à :

• maintenir les tests à jour,

• automatiser leur exécution,

• et respecter les seuils de couverture et d’analyse.